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REMARKS/ARGUMENTS 

In the specification, the first paragraph beginning at Line 5 on Page 2 has been amended 
to update the cross reference of the Application with United State Patent Numbers. 

Claims 1-24 are pending in this application. Claims 25-39 has been cancelled. 

Claim Rejections - 35 U.S.C. § 103 

The Patent Office rejected claims 1, 2, 13, and 14 under 35 U.S.C. § 103(a) as 
being unpatentable over Cockrill et al. ("Cockrill", U.S. Patent Number 6,473,740) in 
view of Gilchrist et al. ("Gilchrist", U.S. Patent Number 5,768,505). Claims 3-6, 8-12, 
15-18, 20-24 are rejected under 35 U.S.C. § 103(a) as being unpatentable over Cockrill 
in view of Gilchrist and further in view of Saulpaugh et al. ("Saulpaugh", U.S. Patent 
number 5,590,334). Applicant respectfully traverses these rejections. 

The present invention is directed to a universal information appliance 
management system which allows content/service providers to control distribution of the 
content or service. Importantly, the architecture of the present invention includes 
dynamic base objects (DBO). Each DBO implements a defined behavior, uses 
capabilities of another DBO, and provides a service to another object. The content/service 
may be encapsulated by dynamic base objects such as content DBOs. Additionally, 
transaction information may be encapsulated in a content DBO, which allows the content 
DBO to control the use of its encapsulated content. The transaction DBO may be utilized 
for containing transaction information such as billing information and security 
information, and transmitting transaction data. 

To establish prima facie obviousness of a claimed invention, all the claim 
limitations must be taught or suggested by the prior art. In re Ryoka, 180 U.S.P.Q. 580 
(C.C.P.A. 1974). See also In re Wilson, 165 U.S.P.Q. 494 (C.C.P.A. 1970). 

Further, "to establish a prima facie case of obviousness, three basic criteria must 
be met. First, there must be some suggestion or motivation, either in the references 
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themselves or in the knowledge generally available to one of ordinary skill in the art, to 
modify the reference or to combine reference teachings. Second, there must be a 
reasonable expectation of success. Finally, the prior art reference (or references when 
combined) must teach or suggest all the claim limitations ." (emphasis added) (MPEP § 
2143). If an independent claim is nonobvious under 35 U.S.C. § 103, then any claim 
depending therefrom is nonobvious. (emphasis added) In re Fine, 837 F.2d 1071, 5 
USPQ2d 1596 (Fed. Cir. 1988). 

Claims 1 and 13 stand rejected under 35 U.S.C. § 103(a). Claims 1 and 13 each 
recite elements of "an encapsulated transaction object" and "the transaction object is 
capable of transmitting data related to the stored occurrence of the utilization event over a 
network." As noted by the Examiner, Cockrill fails to teach, suggest, or disclose the 
element of "encapsulated transaction object" (Office Action, Page 3). Applicant 
maintains that Cockrill also fails to teach, suggest, or disclose "the transaction object is 
capable of transmitting data related to the stored occurrence of the utilization event over a 
network" (emphasis added) as recited in Claims 1 and 13. The Examiner has relied on 
Cockrill for the teaching of "transaction object," citing passages in Column 4, lines 35-56 
and Column 7, lines 60-67 of Cockrill. The text from Cockrill cited by the Examiner 
discloses: 

whether the customer is presently registered and authenticated with the 
network. If the customer is not presently registered, the network enables the 
customer to register with the network by providing identity and payment 
information. The identity information provided by the customer preferably 
includes a member identifier and a password for use with the network, as 
well as an electronic mail ("email") address. The payment information 
preferably includes a credit card number, or other information usable to 
charge the customer for purchases. As part of registration process, the 
network preferably verifies the provided payment information. At the 
conclusion of registration process, the registered customer is permitted to 
purchase the item. As a result of the purchase, the purchased item is provided 
to the customer, and a transaction record is created that identifies the 
customer, the merchant, and the amount of the purchase. The visual user 
interfaces for these registration and purchase processes are preferably 
cobranded with the trademarks of the merchant and the operator of the 
network, to indicate that both parties are collaborating in providing the 
purchasing experience enjoyed by the customer. (Column 4, lines 35-56) 
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As a result of the purchase, the purchased item is provided to the 
customer, and a transaction record is created that identifies the customer, the 
merchant, and the amount of the purchase. The visual user interfaces for 
these registration and purchase processes are preferably cobranded with the 
trademarks of the merchant and the operator of the network, to indicate that 
both parties are collaborating in providing the purchasing experience enjoyed 
by the user. (Column 7, lines 60-67) 

Applicant respectfully submits that the cited passages of Cockrill merely describe 
a transaction record that is created as a result of a purchase. The transaction record in 
the cited passages of Cockrill is a record of a certain transaction (e.g. purchase) which 
identifies the customer, the merchant, and the amount of the purchase. However, in the 
present invention, a "transaction object" is a dynamic base object (DBO) which 
implements a defined behavior and uses capabilities of other DBO's. Nowhere does 
Cockrill indicate that "transaction record" utilized by the transaction network implements 
a defined behavior such as "transmitting data" or uses capabilities of other objects. Thus, 
"transaction record" in Cockrill is not equivalent to "transaction object" in the present 
invention. 



Furthermore, the ancillary reference, Gilchrist, does not make up for the defects 
of Cockrill. The Examiner states that Gilchrist teaches the steps of "encapsulated 
transaction object" as recited in Claims 1 and 13, citing in Column 3, lines 1-25 of 
Gilchrist which reads: 



All messages received by a system in which the framework is 
implemented can be defined on this core object structure. Another set of 
objects and methods define the processing steps required for a mail server 
to process a message. A message is received as a class of message objects, 
which are assigned a message type that determines the subsequent 
processing steps to which the message object is subjected. For example, a 
message might be assigned to be a SNADS-class message type or an 
SMTP-class message type. As a message is processed, the objects of 
which it is comprised are changed, so that the message processing can be 
interrupted and then resumed without loss or duplication of processing 
steps. Because the mail server processing system is provided as an OOP 
framework, object methods that process message objects corresponding to 
particular e-mail protocols can be easily integrated into an implementation 
of the framework without changing the mail server system. Framework 
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users are assured that e-mail function object methods defined on the 
framework structure of classes and subclasses will operate with the core 
framework objects and methods to process messages in the desired 
manner. In this way, a framework user can define object methods that 
process new e-mail protocols to tailor the mail server system to their 
particular requirements without modifying the entire system and without 
recompiling the system programming. This reduces the time and cost 
needed to implement specific mail server changes to an e-mail gateway 
system, (emphasis added) 

The Applicant disagrees. This passage of Gilchrist merely teaches an Object 
Oriented Program (OOP) framework in which a user can define object methods (for 
example, message objects and methods) that process new e-mail protocols to tailor the 
mail server system to their particular requirements without modifying the entire system or 
without recompiling the system programming. In other words, the OOP framework in 
Gilchrist allows a user to utilize any e-mail system message protocol standard through 
message objects and methods which define the processing steps required for a mail server 
to process a message. In contrary, the Applicant's management system allows 
content/service providers to control distribution of the content or service though content 
DBOs encapsulating content/service and transaction objects which contain transaction 
information. 

Applicant respectfully submits that nowhere in Gilchrist is a "transaction object" 
which is encapsulated in content DBOs, or utilized for containing transaction information 
such as billing information and security information disclosed, suggested or taught. Thus, 
Gilchrist fails to teach, suggest, disclose "an encapsulated transaction object," or "the 
transaction object is capable of transmitting data related to the stored occurrence of the 
utilization event over a network," as recited in Claims 1 and 13. 

Additionally, the other ancillary reference, Saulpaugh, fails to disclose, teach or 
suggest the above discussed elements recited in Claims 1 and 13. Saulpaugh merely 
teaches an object-oriented message passing system and a method for transferring 
messages between a client task and a server task with a high level of structural 
granularity and less memory requirement. The object-oriented message passing system 
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may create and maintain a set of message objects (which are associated with particular 
port objects) and port objects (which represent resources that correspond to services 
provided by a server task). 

Therefore, Saulpaugh does not teach, suggest or disclose "encapsulated 
transaction object " or "the transaction object is capable of transmitting data related to the 
stored occurrence of the utilization event over a network," as recited in Claims 1 and 13. 

Accordingly, any of the references (Cockrill, Gilchrist, and Saulpaugh), either 
alone or in combination thereof, fails to teach, suggest, or disclose the above discussed 
elements claimed in independent Claims 1 and 13. Thus, Applicant respectfully submits 
that independent Claims 1 and 13 are nonobvious under 35 U.S.C. § 103. Removal of the 
pending rejections to Claims 1 and 13 under 35 U.S.C. §103 is respectfully requested. 
Claims 2-12 depend on Claim 1. Claims 14-24 depend on Claim 13. Claims 2-12, and 14- 
24 are believed to be allowable based on their dependence upon allowable base claims. 
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CONCLUSION 

In light of the foregoing amendments and remarks, Applicant respectfully 
requests a timely Notice of Allowance. 

Respectfully submitted, 



Gateway, Inc., 



Dated: February 4, 2005 




Reg. No. 53,198 

Sunah K. Lee 

Suiter - West pc llo 

14301 FNB Parkway, Suite 220 

Omaha, NE 68154 

(402) 496-0300 telephone 

(402) 496-0333 facsimile 
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